本篇是故事一的「查證」篇。

本篇要回答：需求走偏時，第一個該查證的不是規格，而是「誰真正承擔結果」——這件事當時被我簡化成什麼樣子？

當時發生了什麼

Day 01 的現場還有一個沒被寫出來的前提：在我當時的想像裡，「客戶」是一個單一窗口——我把問題丟過去，答案傳回來，像一顆需求轉接頭（adapter）。FOV 多大？問客戶。可以用 GigE 嗎？問客戶。誤判率可以接受多少？也問客戶。

這個「單一窗口」的想像不是誰教我的，是我自己長出來的工作習慣——這也是它值得複盤的原因：換一個專案，它還是會跟著我進場。

問題在於，轉接頭不承擔風險，但真實的利害關係人承擔。這個專案裡至少存在幾種不同的人：產線上實際操作與看警報的人、決定要不要停線的人、替誤判與漏判付出成本的人、在驗收單上簽名的人。他們口中的同一個詞，指的常常不是同一件事。

我原本怎麼判斷

當時的假設是：需求是一包可以「取得」的東西，只要問對窗口就能拿到完整規格。這個假設的方便之處在於，它讓工程師可以把所有不確定性外包出去——答案是客戶給的，錯了也是客戶的事。

現在看，這其實是把兩件事混在一起：利害關係人有權決定「要承擔什麼結果」，但他們不欠工程師一份技術判斷。把「誤判率可以接受多少」直接丟給對方，等於要求對方在沒有技術選項與代價分析的情況下憑空報數字。

我怎麼查證或重現

查證從定義開始。教科書版（PMBOK Guide 的利害關係人概觀）：會影響成果成敗，或會被成果影響的人。我自己的現實版註解：最後得去面對老闆、客戶臭臉的那個人。兩個定義之間隔著的，就是這一篇要處理的距離：教科書定義畫出範圍，現實定義指出重量——臭臉是有人要面對的，而那個人通常不是列規格的工程師。

順著這兩個定義，把專案裡的角色並排，做一張角色責任表。以下依實際專案結構去識別化並簡化（職稱與分工已調整）：

把「準確」這個詞放進表裡就會現形：操作人員的「準確」是不要一直誤報吵人；品質部門的「準確」是漏判率壓到多少以下；主管的「準確」還包含「不要動不動停線」。同一個詞，三種驗收條件。

區分證據等級。已確認事實：PMBOK Guide 的利害關係人定義（可查閱原文）。合理推論：當時的提問方式沒有區分這些角色，等於預設他們的需求彼此一致。邊界說明：上表為去識別化後的簡化示意，不對應特定公司與人員；換一個專案，每個角色的說法必須重新訪談取得，不能沿用這張表。

今天留下什麼方法

留下兩個可重用的東西。

第一，角色責任表模板：每個專案開工前，列出角色、是否實際使用、決策權、承擔的風險、驗收責任五欄，填不出來的格子就是還沒問清楚的需求。

第二，一條分工原則：

利害關係人可以決定要承擔什麼結果，但工程師仍然必須把技術限制整理成可以判斷的選項。

這也是事故調查需要回看原始目標與角色責任的原因：出事之後問「當初這個風險是誰決定接受的」，如果答案是「沒有人明確決定過」，那本身就是一項系統性缺口。

下一篇（Day 03）處理我當時最常用的句型——「可以嗎？」——以及它如何把工程判斷悄悄退回給客戶。